Niels Thykier: debputy v0.1.21
Earlier today, I have just released debputy version 0.1.21
to Debian unstable. In the blog post, I will highlight some
of the new features.
Package boilerplate reduction with automatic relationship substvar
Last month, I started a discussion on rethinking how we do
relationship substvars such as the $ misc:Depends . These
generally ends up being boilerplate runes in the form of
Depends: $ misc:Depends , $ shlibs:Depends where you
as the packager has to remember exactly which runes apply
to your package.
My proposed solution was to automatically apply these substvars
and this feature has now been implemented in debputy. It is
also combined with the feature where essential packages should
use Pre-Depends by default for dpkg-shlibdeps related
dependencies.
I am quite excited about this feature, because I noticed with
libcleri that we are now down to 3-5 fields for defining
a simple library package. Especially since most C library
packages are trivial enough that debputy can auto-derive
them to be Multi-Arch: same.
As an example, the libcleric1 package is down to 3
fields (Package, Architecture, Description)
with Section and Priority being inherited from the
Source stanza. I have submitted a MR to show case the
boilerplate reduction at
https://salsa.debian.org/siridb-team/libcleri/-/merge_requests/3.
The removal of libcleric1 (= $ binary:Version ) in that MR
relies on another existing feature where debputy can auto-derive
a dependency between an arch:any -dev package and the library
package based on the .so symlink for the shared library.
The arch:any restriction comes from the fact that arch:all and
arch:any packages are not built together, so debputy cannot
reliably see across the package boundaries during the build (and
therefore refuses to do so at all).
Packages that have already migrated to debputy can use
debputy migrate-from-dh to detect any unnecessary
relationship substitution variables in case you want to clean
up. The removal of Multi-Arch: same and intra-source
dependencies must be done manually and so only be done so
when you have validated that it is safe and sane to do. I was
willing to do it for the show-case MR, but I am less confident
that would bother with these for existing packages in general.
Note: I summarized the discussion of the automatic relationship
substvar feature earlier this month in
https://lists.debian.org/debian-devel/2024/03/msg00030.html
for those who want more details.
PS: The automatic relationship substvars feature will also
appear in debhelper as a part of compat 14.
Language Server (LSP) and Linting
I have long been frustrated by our poor editor support for Debian packaging files.
To this end, I started working on a Language Server (LSP) feature in debputy
that would cover some of our standard Debian packaging files. This release
includes the first version of said language server, which covers the following
files:
Specifically for emacs, I also learned two things after the upload. First, you
can auto-activate eglot via eglot-ensure. This badly feature interacts with
imenu on debian/changelog for reasons I do not understand (causing a several
second start up delay until something times out), but it works fine for the other
formats. Oddly enough, opening a changelog file and then activating eglot does
not trigger this issue at all. In the next version, editor config for emacs will
auto-activate eglot on all files except debian/changelog.
The second thing is that if you install elpa-markdown-mode, emacs will accept
and process markdown in the hover documentation provided by the language server.
Accordingly, the editor config for emacs will also mention this package from
the next version on.
Finally, on a related note, Jelmer and I have been looking at moving some of this
logic into a new package called debpkg-metadata. The point being to support
easier reuse of linting and LSP related metadata - like pulling a list of known
fields for debian/control or sharing logic between lintian-brush and
debputy.
Most of the effort has been spent on the Deb822 based files such as debian/control, which comes with diagnostics, quickfixes, spellchecking (but only for relevant fields!), and completion suggestions. Since not everyone has a LSP capable editor and because sometimes you just want diagnostics without having to open each file in an editor, there is also a batch version for the diagnostics via debputy lint. Please see debputy(1) for how debputy lint compares with lintian if you are curious about which tool to use at what time. To help you getting started, there is a now debputy lsp editor-config command that can provide you with the relevant editor config glue. At the moment, emacs (via eglot) and vim with vim-youcompleteme are supported. For those that followed the previous blog posts on writing the language server, I would like to point out that the command line for running the language server has changed to debputy lsp server and you no longer have to tell which format it is. I have decided to make the language server a "polyglot" server for now, which I will hopefully not regret... Time will tell. :) Anyhow, to get started, you will want:
- debian/control
- debian/copyright (the machine readable variant)
- debian/changelog (mostly just spelling)
- debian/rules
- debian/debputy.manifest (syntax checks only; use debputy check-manifest for the full validation for now)
$ apt satisfy 'dh-debputy (>= 0.1.21~), python3-pygls'
# Optionally, for spellchecking
$ apt install python3-hunspell hunspell-en-us
# For emacs integration
$ apt install elpa-dpkg-dev-el markdown-mode-el
# For vim integration via vim-youcompleteme
$ apt install vim-youcompleteme
Minimal integration mode for Rules-Requires-Root
One of the original motivators for starting debputy was to be able to get rid of
fakeroot in our build process. While this is possible, debputy currently does
not support most of the complex packaging features such as maintscripts and debconf.
Unfortunately, the kind of packages that need fakeroot for static ownership tend
to also require very complex packaging features.
To bridge this gap, the new version of debputy supports a very minimal integration
with dh via the dh-sequence-zz-debputy-rrr. This integration mode keeps
the vast majority of debhelper sequence in place meaning most dh add-ons
will continue to work with dh-sequence-zz-debputy-rrr. The sequence only
replaces the following commands:
The installations feature of the manifest will be disabled in this integration mode to avoid feature interactions with debhelper tools that expect debian/<pkg> to contain the materialized package. On a related note, the debputy migrate-from-dh command now supports a --migration-target option, so you can choose the desired level of integration without doing code changes. The command will attempt to auto-detect the desired integration from existing package features such as a build-dependency on a relevant dh sequence, so you do not have to remember this new option every time once the migration has started. :)
- dh_fixperms
- dh_gencontrol
- dh_md5sums
- dh_builddeb